Embedded Systems
In general, an embedded system may be described as a special purpose computing system designed to perform one or a few dedicated functions. Embedded systems are commonly used in consumer devices like personal digital assistants, mobile phones, videogame consoles, microwaves, washing machines, alarm systems, and digital cameras. In addition to the consumer space, embedded systems are used in nearly every industry, from telecommunications to manufacturing, and from transportation to medical devices. In fact, embedded systems are so commonly in use today that it is not feasible to exhaustively list specific examples.
The term “embedded system” does not have a precise definition, and determining what is and is not an embedded system can be difficult. For example, a general purpose computer, such as a laptop, is not typically characterized as an embedded system. However, a laptop is usually composed of a multitude of subsystems such as the hard disk drive, the motherboard, the optical drive, the video processing unit, and various communication devices. Many of the individual subsystems comprising the laptop may themselves be embedded systems.
The complexity of embedded systems varies from those with a single microcontroller chip and a light emitting diode to those with multiple microprocessor units and various peripheral communication interfaces and mechanical parts. Additionally, embedded systems range from those having no user interface at all to those with full user interfaces similar to a desktop operating system. Manufacturers of modern microprocessors are increasingly adding components and peripheral modules to their microprocessors, creating what may be thought of as embedded processors. This type of embedded system is often referred to as a system on a chip (SoC). A simple example of a system on chip is an application-specific integrated circuit (ASIC) packaged with a universal serial bus (USB) port.
There are many advantages to using embedded systems. For example, typically, an embedded system is designed to do some specific task, as opposed to being a general purpose computer with a wide range of programming and performance features for performing many different tasks. One benefit to using embedded systems as opposed to general computing devices stems from the fact that embedded systems are dedicated to specific tasks. As a result, design engineers can optimize the embedded system for the desired task, which assists in reducing the size and cost of the device as well as increasing its reliability and performance. Furthermore, functionalities can be designed into an embedded system that would not be feasible using hardware alone. By using software to accomplish some of the functionality that would have been accomplished in hardware, designers may specify and define certain functionality later in the design cycle than was previously possible. An additional advantage is that embedded system designs can often be reconfigured for different functionality with less engineering overhead than a design done strictly in hardware can. As a result, design reuse increases and time to market is lowered.
The software written for embedded systems is generally referred to as “firmware.” Thus, the program used to control the hardware of an embedded system is referred to hereafter interchangeably as either software or firmware. Firmware is often stored on read only memory (ROM) based storage devices. For example, flash-based read only memory or electronically erasable read only memory (EEPROM) devices are often used to store firmware. The firmware controls the various features, functioning, and interfaces of the embedded system. Thus, a digital video disk player will have firmware that processes the appropriate response to an input such as the user pressing the “power” button or the “play” button. Additionally, the firmware in this example would control the storage mechanism and the digital processing circuitry to decode and output onto the appropriate ports the video and audio signals stored on the video storage medium.
A further advantage of embedded systems is the ability to update the firmware, which provides longer term support and flexibility, a benefit often not possible with purely hardware based systems. Updating an embedded systems firmware is often referred to as “flashing” the device. For example, manufacturers of most modern digital video disk players typically provide a means for the firmware stored on the device to be erased and a new version stored in place of the erased firmware. As stated, a primary function of allowing the firmware to be updated is to prolong the usable life of the embedded system. For example, the firmware of a digital video disk player could be updated to support new video encoding specifications. The new firmware file may be retrieved from an optical disk or other data storage medium, retrieved via connecting the device to a general purpose computer, or directly from the Internet via an Ethernet port.
Embedded System Development
Although packaging software and hardware together to create an embedded system provides for great flexibility and increased functionality, it also complicates the design. The development of an embedded system requires knowledge of software and hardware design. Additionally, an embedded system development engineer will need to use tools to design and then test the electrical, mechanical, and software components of the design. Not only must the individual components be designed and tested, but the combination or interaction of the electrical, mechanical, and software components must be tested together to ensure proper functionality. Furthermore, complex devices require significantly more complex firmware to operate than do simple devices. As a result, the knowledge and skill required to design an embedded system and program its firmware increases as the complexity of the design increases.
The design of an embedded system is further complicated by the fact that, in many instances, the hardware and software are developed concurrently. This prevents the verification engineers from using an actual embodiment of the designs hardware as the target with which to test the software on. In the absence of an actual embodiment of the hardware as a test target, special design and verification tools are needed to test the software. One solution available to the embedded system engineer is to test the software with a simulation of the hardware. The simulation could be a behavioral software simulation of the design, or it could be a hardware emulator configured to mimic the design. It is often possible with modern tools to simulate the hardware and test the software with the same general purpose computing device (e.g., a computer workstation.) Using a simulation of the hardware as the target with which to test the software component of the design is often called host simulation. Embedded system developers frequently employ host simulation due to the fact that in a host simulation environment, testing methods, as well as hardware and software design changes, can be quickly developed and executed.
Employing host simulation in the test methodology may provide a decrease in design time and allow the hardware and software to be developed and tested concurrently. However, even using advanced host simulation tools, it is typically not possible to test the entirety of a software package using host simulation. Embedded software typically contains portions referred to as the “device layer” or “device driver.” These portions of the software are hardware dependent. More particularly, the device layer portions contain specific references to the actual hardware within the design, such as memory storage location addresses, such as the memory storage location address associated with a particular data storage register. Execution of device layer code in a host simulation environment will often trigger a memory access exception. More particularly, when a specific instruction within the firmware specifies that data from a particular memory storage location address be read and that particular address has not been explicitly allocated by the host simulation environment, a memory access exception will result.
This limitation in host simulation is commonly overcome by replacing the device driver sections of the software with direct function calls to the hardware simulator component of the host simulation environment. Although this method typically overcomes the limitation, it requires the developer to maintain two copies of the software. More particularly, one version of the software must be maintained to test using host simulation and one version of the software that runs on the actual hardware must be maintained. Maintaining two copies of the software creates extra work for the developer and adds a significant amount of overhead. Additionally, maintaining two copies of the software provides more opportunity and possibility to introduce errors into the software.
Another method of testing hardware-specific software in a host simulation environment is to allocate a memory array to simulate the memory-mapped hardware. The hardware memory accesses can be redirected to this simulated memory array either by changing the hardware addresses in the code itself or by using linker options. One advantage to employing a simulated memory array is that it allows for host simulation to be implemented while requiring that few, if any, changes be made to the software. However, implementing host simulation with a simulated memory array also has some basic limitations. For example, when a memory mapped hardware element is accessed for a read or a write operation, the action taken by the embedded systems hardware in response to this memory access is often not a simple read or write operation. Therefore, a simulated memory array is insufficient to simulate the memory mapped target hardware and provide a suitable testing environment.
Still another method for dealing with memory access exceptions in host simulation testing is to catch the memory access exception that results from a hardware dependant memory access and redirect the memory access instructions to the hardware simulator component of the host simulation environment. Once the hardware simulator receives a memory access instruction, it calls the appropriate hardware simulator function to process the memory access instruction. Once the hardware simulator has performed its operation, the host simulation process may be resumed. This method is often referred to as implicit memory access (IMA).
Although implicit memory access provides a means to test hardware dependant software, there are numerous limitations with implicit memory access systems as well. First, it may not be possible with an implicit memory access system to change the attributes of a memory access instruction. For example, Linux reserves the address range of 0xC000—0000 to 0xFFFF_FFFF for use by the kernel. As a result, an instruction seeking to access a memory storage location within that address range will produce a second memory access exception. Second, memory access systems cannot handle multiple threads at once. For example, the smallest memory page size in both the Linux and Windows operating systems is 4,000 bytes. Therefore, if multiple threads seek to access memory storage locations having addresses that lie within the same memory page, a change in the attributes of the memory access instruction for one thread will interfere with the operation of the other threads. Third, any changes to the memory access instruction attributes by an implicit memory access system must be reverted, although this problem may be mitigated by various methods, such as using a flag to halt execution of the host simulation environment, wherein the changes may be reverted. However, some operating systems and software debuggers used for performing host simulation do not allow particular flags to be used. Visual Studio debugger for example, reserves use of the processor Trap flag for setting breakpoints and its use by other applications interferes with the debugger. As a result, employing a method involving a flag to revert any changes made to the memory access instructions attributes is not always possible.